<p><code>async</code> - when <code>true</code>, the paper uses asynchronous rendering to display graph cells (i.e. cells added either with <a href="#dia.Graph.prototype.resetCells"><code>graph.resetCells()</code></a> or <a href="#dia.Graph.prototype.addCells"><code>graph.addCells()</code></a> methods).</p>

<p>This is very useful for adding a large number of cells into the graph. The rendering performance boost is significant and it doesn't block the UI. However, asynchronous rendering brings about some caveats – at the time when you call another function...</p>

<ul>
	<li>...the views of freshly added cell models may not have yet been added to this paper's DOM.</li>
	<li>...some views may have been removed from the DOM by the <a href="#dia.Paper.prototype.options.viewport"><code>paper.options.viewport</code></a> function.</li>
	<li>...views already present in the DOM may not have been updated to reflect changes made in this paper's graph since the last render.</li>
	<li>...re-rendering may have been manually disabled with <a href="#dia.Paper.prototype.options.frozen"><code>paper.options.frozen</code></a> or <a href="#dia.Paper.prototype.freeze"><code>paper.freeze()</code></a>.</li>
</ul>

<p>This is an issue because certain CellView/Paper methods require the view to be updated and present in the DOM to function properly (e.g. <a href="#dia.Paper.prototype.findViewByModel"><code>paper.findViewByModel()</code></a> or <a href="#dia.Element.prototype.findView"><code>element.findView()</code></a>/<a href="#dia.Link.prototype.findView"><code>link.findView()</code></a>, as well as <a href="#dia.Paper.prototype.getContentBBox"><code>paper.getContentBBox()</code></a> and <a href="#dia.ElementView.prototype.getBBox"><code>elementView.getBBox()</code></a>/<a href="#dia.LinkView.prototype.getBBox"><code>linkView.getBBox()</code></a>).</p>

<p>The problem may be circumvented in several Paper methods via the <code>useModelGeometry</code> option to force using model calculations instead of view measurements (e.g. <a href="#dia.Paper.prototype.getContentBBox"><code>paper.getContentBBox()</code></a>, <a href="#dia.Paper.prototype.getContentArea"><code>paper.getContentArea()</code></a>, <a href="#dia.Paper.prototype.scaleToFit"><code>paper.scaleToFit()</code></a>, <a href="#dia.Paper.prototype.fitToContent"><code>paper.fitToContent()</code></a>). In this case, the methods refer to the (always up-to-date) model data.</p>

<p>For the methods that truly need a to refer to a CellView, one way to prevent inconsistencies is to rely on the <code>'render:done'</code> <a href="#dia.Paper.events">paper event</a>. This event signals that all scheduled updates are done and that the state of cell views is consistent with the state of the cell models.</p>

<p>Alternatively, you may trigger a manual update immediately before a sensitive function call. JointJS offers several suitable methods:</p>

<ul>
	<li><a href="#dia.Paper.prototype.requireView"><code>paper.requireView()</code></a> - bring a single view into the DOM and update it.</li>
	</li>
	<li><a href="#dia.Paper.prototype.dumpViews"><code>paper.dumpViews()</code></a> - bring all views into the DOM and update them.</li>
	<li><a href="#dia.Paper.prototype.updateViews"><code>paper.updateViews()</code></a> - update all views.</li>
	</li>
</ul>
